home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13225 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: EU.net!sun4nl!xs4all!usenet
  2. From: martijnl@xs4all.nl (Martijn Lievaart)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Unable to use 'delete' after 'new'
  5. Date: Sun, 24 Mar 1996 11:03:44 GMT
  6. Organization: XS4ALL, networking for the masses
  7. Message-ID: <4j3a71$n10@news.xs4all.nl>
  8. References: <4iursi$ibc@lisa.iosphere.net>
  9. NNTP-Posting-Host: mas01-09.dial.xs4all.nl
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. ianq@sonetis.com (Ian V. Quickmire) wrote:
  13.  
  14. (snip)
  15. >I tried the basic delete [] iColsize from the calling function, and got a
  16. >memory exception.
  17. (snip)
  18. >Up until I do the SQLFetch, I can do a 'delete [] sPassStr' fine.
  19. >After the Fetch is executed, if I do a delete, I get a memory exception.
  20.  
  21. >Any ideas?
  22.  
  23. I'ld say the problem is not in new/delete. I think you're suffering
  24. from a bug somewhere else in your program that overwrites memory where
  25. it is not supposed to.
  26. Somehow the pointer gets corrupted and when freeing this corrupted
  27. pointer, Windows (quite rightly) complains. I would use a debugger or
  28. messageboxes to trace the program and see what pointer new returned,
  29. what pointer you're deleting, and where it gets corrupted.
  30.  
  31. How can this happen? Probably array overrun. This is the most common
  32. cause. Take f.i.
  33.     char buf[8];
  34.     strcpy(buf, "12345678");
  35. This will write 1 byte to many (the terminating '\0').
  36.  
  37. C++ makes it very easy to shoot yourself in the foot in a zillion
  38. ways, there are indeed a zillion ways to corrupt a pointer. My advice:
  39. use a debugger, investigate, have a flash of insight, never make that
  40. mistake again. Works better than when someone points out the bug.
  41.  
  42. On the other hand, it might be something else, though I would bet on
  43. pointer corruption.
  44.  
  45. Hope this helps,
  46. Martijn.
  47.  
  48. BTW, see if your debugger supports the 386-hardware breakpoints, they
  49. can speed up this kind of debugging. Set a hardware breakpoint on the
  50. location contianing the pointer (not where the pointer points to but
  51. where the pointer itself is stored) and the debugger will break at the
  52. statement that corrupts the pointer.
  53.  
  54.      /~~~~~| /~~~~~| /~~~~~~|~~~~~\~~~~~\~~~~|~~~~~|   We now return to our
  55.     /      |/      |/       |   o  |  o  |  |   +-|     regularly scheduled
  56.    /   /|     /|   |   /|   |  ___/  ___/   |   +-|          flame-throwing
  57. ../___/.|____/.|___|__/~|___|_|..|__|..|_____|_____|...martijnl@xs4all.nl..
  58.  
  59.